With some particular applications, it may be difficult to debug one or more problems that are detected when the application is executed. This problem may be compounded when the application is user-configurable as it is difficult to determine if the problem lies with the application itself, with a user's configuration of the application, or with the application's environment, i.e., the operating system on which the application is running.
A typical way to debug an application is to install one or more special debugging files and activate debug logging while the application is executing so that data is collected in a log file. The log file can then be analyzed to identify the problem. This method can be time consuming and unreliable, especially if the identified problem only shows up in a particular environment. It is not uncommon that a developer trying to debug a problem is not associated with the users who have experienced the problem. The developer may have difficulty conceiving certain configuration aspects that are utilized by the users in particular environment configurations.
For example, a software package called DIRECTSHOW produced by MICROSOFT CORP. utilizes multiple user-configurable filters that are collectively referred to as a filter graph. If users of a DIRECTSHOW application experiences problems with the application, they typically rely on developers from MICROSOFT CORP. to identify the problem and provide a solution to the problem.
As it turns out, it is very difficult to determine which DIRECTSHOW filters are being used in the filter graph, how the filters communicate (or connect) with each other, and how the filter graph changes during the course of the application's lifetime. If such information could be collected quickly from an object within the application that controls filters used in the application, the developer would be better equipped to provide a clear solution to the problem.